Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-crocker-pci-00.txt < prev next >

Wrap

Text File | 1993-06-16 | 22.3 KB | 620 lines

Internet Draft PCI (Expiration: 3/94) D. Crocker Network Working Group D. Crocker Internet Draft <STIF> Silicon Graphics, Inc. Expiration <3/94> 9 June 1993 Encoding for Personal Contact Information (PCI) STATUS OF THIS MEMO This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. (Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate is use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the Internet Draft abstract listing contained in the IETF Shadow Directories (cd internet-drafts) to learn the current status of this or any other Internet Draft. SUMMARY Extensive use of Internet electronic mail demonstrates a need to be able to communicate various descriptive information about participants. The information ranges from telephone and postal addressing, to an indication of the media supported by their electronic mail and information processing environment. This specification provides a basis for encoding such "PCI" business card information by using the STIF [CROC93] syntax. A MIME Content sub-type is defined for carriage of PCI information. TABLE OF CONTENTS 1. INTRODUCTION 2. MIME Content-Type for Carriage of PCI Information 3. PCI FRAMEWORK 3.1 Basic Syntax 4. ADDRESSING DETAIL 4.1. Electronic Mail Detail 4.2. Postal Mail Detail 4.3. Facsimile Mail Detail 4.4. Telex Mail Detail 5. DESCRIPTION DETAIL 6. CAPABILITIES DETAIL 7. REFERENCES 8. SECURITY CONSIDERATIONS 9. ACKNOWLEDGEMENTS 10. CONTACT A. Example of Personal Contact Information 1. INTRODUCTION Extensive use of Internet electronic mail demonstrates a need to be able to communicate various descriptive information about participants. The information ranges from telephone and postal addressing, to an indication of the media supported by their electronic mail and information processing environment. This specification provides a basis for encoding such "PCI" business cardinformation by using the STIF [CROC93] syntax. EMail often contains a set of information headers, or free-format text, at the end of the message intended to convey various information about the originator of the message. There is no formal specification which permits automated exchange of such information so that it can be incorporated into an on-line information base. Further, there is no way for a sender to provides recipients with similar information about each other. At its simplest, the PCI/STIF/MIME mechanism permits the exchange of "business card" information in an automated fashion. Hence, its benefits should be an on-line equivalent to that derived when business associates exchange contact information. This specification provides a detailed structure for encoding the wide range of contact and description information needed by communicants. It includes fine-grained specification for delivery through various media and specification of the human communication media support available to a participant. A MIME Content-type is defined for carriage of PCI information. 2. MIME Content-Type for Carriage of PCI Information PCI information is encoded with the STIF syntax, and can be carried in MIME [BORE92] messages: MIME type name: TEXT MIME subtype name: PCI Required parameters: none Optional parameters: charset = xxx This defines the alternate STIF character set. Legal character sets are the same as defined in MIME. Encoding considerations: Alternate character set characters, and some US-ASCII characters cannot be sent through some transport services directly. Transports that do not support such data should enocode the data appropriately. Where possible, it is recommended that quoted-printable be used, to preserve some level of human-readability. Security considerations: See separate section in the documen t. Published specification: This document and its companion, Structured Text Interchange Format (STIF), with additional specification at the end of this section. Rationale: Provides human- and machine-processable means of encoding common personal contact information. This will permit automated processing, such as for maintaining personal files of contact information. Contact-info: See Contact section, below. Detail specific to MIME-based usage: Within a MIME body-part, PCI data are to be encoded as a series of headers, in the style of RFC 822. Each header has a name, which serves as the reference key to a set of data. Usually, the key should be a version of the person's name which has been stripped of seconday text, such as titles and salutations: pci-entry = *( pci-key ":" pci-info ) pci-key = field-name ; specifies the string to be used for filing the entry, usually name minus titles, etc. > field-name = < As defined in RFC822> 3. PCI FRAMEWORK PCI permits structured, extensible specification of information about a person or some other "reachable" resource. Use of the STIF syntax permits machine processing of the PCI content. PCI entries are specified one per STIF Header, rather than in the compressed, list-oriented format of RFC822 which allows multiple addresses per line. Information is specified by a set of STIF fields which are named from a single, flat name space. Extensions to this document are to be registered with IANA, as described in the MIME specification [BORE92]. For convenience, this document discusses the initial set of PCI fields in three different sections. The first provides information about various addressing alternatives, including electronic mail, postal mail, facsimile transmission, and telex transmission. The second set of PCI fields cover descriptive information about a person, such as their personal name, organizational affiliation, title, and telephone contact number. The third set of information specifies the capabilities of the person's electronic mail service. This allows the sender or agent software for the recipient to determine what alternate routing or gateway translations are to be provided. 3.1 Basic Syntax pci-part = 1*( pci-descrip / pci-capable / pci-nest ) ; described below pci-nest = nest-name "<" pci-info ">" ; PCI-specific use of STIF nesting capability nest-name = "work" / "home" / x-pci x-pci = "x-" word ; private extension Note that RFC 822 lists of addresses, within a field, have been modified to be lists of STIF headers. PCI entries may contain two types of information: 1. Addressing Detail provides basic contact information, sufficient to allow contact via a variety of transport mechanisms, such as postal, telex and email. 2. Description Detail provides information about the addressee, some of which may be required by some media, but which may otherwise be of interest. The addressee's name and the name of their organization are examples of such information. 3. Capabilities Detail provides guidance about the addressee's support of various on-line media and, possibly, conversions they would prefer when they lack a capability. For example, they may have a fax machine but not have on-line graphics capabilities and they may wish that graphics body-parts be sent to them via facsimile. (This specification does not dictate behavior by electronic mail transport services, so that use of capabilities information is outside of the scope of this document.) 4. ADDRESSING DETAIL 4.1. Electronic Mail Detail Specification of electronic mail addresses is similar to the style used for RFC 822-based encoding, except that reference to the formal, presentation name of a person is separated into its own field, since it may be used without any reference to email. Further, an email address may be characterized as to type. This is intended to allow user agents to perform contingent actions, depending upon the type of email address. For example, a reply to a message which includes an email reference to a list or bboard may cause the user agent to obtain confirmation from the sender, so that such addresses are not included in replies automatically and possibly by accident. email = "email" ":" addr-spec [ "/" email-type ] ; standard RFC 822 on-line address, without the human name portion (instead placed in Name field) email-type = "person" / "list" / "list-owner" ; distinguish the type of mail address referent. ; a "list" distributes copies to multiple recipients ; "list-owner" directs the message to the address responsible for administering the named list 4.2. Postal Mail Detail The specified fields refer to typical categories of postal information that are used. Note that such information is order- dependent to the Postal Service. For example, in the United States, an address which contains both a street address and a post office box address is delivered to whichever address is "lower" on the envelope. Courier-delivered mail specification is treated as a type of postal delivery, although it may require additional information, such as the specific courier agency to be used. Also, some courier agencies require the specification of the recipient's telephone number. Since the service provided by one electronic mail gateway may differ from that of another, or the authorization to use it may be restricted, specification of a particular postal gateway is permitted. paper = [name] [org] paper-set [paper-gateway] paper-set = internal / postal / courier / printer << How would you like the printer reference to work?? >> internal = 1*2( dept / mailstop ) ; sufficient for routing within an organization, but not for routing by public postal system mailstop = "stop" ":" ephrase ; address _within_ an organization postal = [internal] drop code geo drop = 1*2( 1*2(street) / pobox ) ; Street or Post Office Box or both ; Note that the last to appear will be used by the postal service street = "street ":" ephrase pobox = "box" ":" ephrase ; postal box code = "code ":" word ; zip code, postal code, or the equivalent postal routing string geo = "geo" ":" city-val "/" region-val "/" country-val ; geographic location city-val = ephrase region-val = ephrase ; state, province, or the equivalent country-val = word ; conforms to the relevant international reference standards courier = postal ; courier-delivered paper mail uses the same base of information as postal [carrier-name] [account] [deliver-by] [phone] ; phone number of recipient usually is required carrier-name = "carrier ":" ephrase ; if a specific company's service is required account = "account ":" ephrase ; string which specifies the account to which charges for usage are to be made. paper-gateway = "paper-gate" ":" addr-spec ; Internet address for gateway system to the paper-based service ; If deliver=paper and no paper-gate is specified, the underlying email transport service must already know of such a gateway 4.3. Facsimile Mail Detail Facsimile addresses are easily specified, since they consist only of a telephone number. However, transmission of facsimile may require essential configuration information, such as the degree of precision to the image to be sent or variations in the cover page to be used. As with postal, the specification may indicate a particular gateway service that is to be used. fax = [name] fax-phone [grain] [cover-name] [phone] [postal / internal] [pagecount] [instruct] [subject] [fax-gateway] ; optional info needed for cover page ; originator User Header must supply info for cover page, also fax-phone = "fax ":" phone-number *( "/" phone-number ) grain = "grain" ":" ("regular" / "fine") cover-name = "cover ":" ephrase ; name of cover page template, if more than one cover page allowed pagecount = "page ":" number ; number of pages, _including cover page_ in the fax instruct = "instruct ":" ephrase ; handling instructions for facsimile operator fax-gateway = "fax-gate" ":" addr-spec ; Internet address for gateway system to the facsimile service ; If deliver=fax and no fax-gate is specified, the underlying email transport service must already know of such a gateway 4.4. Telex Mail Detail telex = telex-addr [answer] [telex-gateway] telex-addr = phrase answer = phrase telex-gateway = "telex-gate" ":" addr-spec ; Internet address for gateway system to the Telex service ; If deliver=telex and no telex-gate is specified, the underlying email transport service must already know of such a gateway 5. DESCRIPTION DETAIL A small set of initial descriptors for an addressee are defined here. The set is by no means intended to be definitive. Rather, it is intended to be indicative of the range of such information that may be useful and appropriate to specify. a-descrip = name / title / org / department / phone / motto / note name = "name" ":" ephrase ; personal name of addressee title = "title" ":" ephrase ; their position within affiliated organization org = "org" ":" ephrase ; name of affiliated organization dept = "dept" ":" ephrase ; name of work group, within affiliated organization phone = "phone" ":" #phone-number ; voice contact phone number for addressee phone-number = < international telephone number, conforming to f.103 international telephone number format > ; e.g., +1 408 249 6205 motto = "motto" ":" ephrase ; descriptive text, associated with addressee, work group, or organization note = "note" ":" ephrase 6. CAPABILITIES DETAIL A sender may choose a delivery address or medium based upon knowing the capabilities of the recipient. Similarly, an electronic mail gateway may choose particular behaviors, such as encoding formats, based upon such knowledge. Such information may be accessible through dynamic query of a directory service. However, this may not be possible. An alternative is to allow the addressee's descriptive information to contain specification of the range of media support available to that addressee. For simplicity, this specification simply provides for listing the range of MIME content types and sub-types that the addressee's system can support. Since stif supports aggregation of references within nested subsets, <a-capable> specifications may be used for _each_ of the nested sets of addressing information. A user's different mailboxes may have different capabilities. a-capable = "support" ":" 1#support ; set of MIME content types/sub- types that are supported by this addressee's email system support = type "/" subtype type = < MIME content-type value > subtype = < MIME content sub-type, as appropriate to the indicated type > 7. REFERENCES [BORE92] Borenstein, N. & Freed, N., "MIME (Multipurpose Internet Mail Extensions): Mechanisms for specifying and describing the format of Internet Message Bodies. March, 1992, Network Information Center, RFC 1341. [CROC82] Crocker, D., Standard for the format of ARPA Internet text messages. August, 1982, Network Information Center, RFC 822. [CROC93] Crocker, D., Structured Text Interchange Format (STIF). Draft, May 1993. 8. SECURITY CONSIDERATIONS This specification covers data encoded within a portion of an email message. It contains addressing and source-identification information which is not specially authenticated. No special provision is made for confidentially of the data. No other security-related concerns apply. 9. ACKNOWLEDGEMENTS STIF developed out of a series of conversations, but was initially focused exclusively for use as enhanced electronic mail headers. Steve Crocker suggested separating the information for use as a personal contact, or PCI, information base. Details for facsimile specification were provided by Alan Katz and Jim Knowles. Additional review and comments were provided by Nathaniel Borenstein, Steve Crocker, Ned Freed, Keith Moore, Marshall Rose and Erik M. van der Poel 10. CONTACT name: David H. Crocker; work <email: dcrocker@sgi.com; org: Silicon Graphics, Inc.; street: 2011 N. Shoreline Blvd.; box: 7311; geo: Mountain View / CA / US; code: 94039-7311; phone: +1 415 390 1804; fax: +1 415 962 8404> A. Example of Personal Contact Information It is common for Internet mail to contain extensive information about its sender. For example: From: "Ole J. Jacobsen" <ole@Csli.Stanford.EDU> Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular) Direct: +1 415 962-2515 (Office) +1 415 998-4427 (Pager) Fax: +1 415 949-1779 (Interop) +1 415 826-2008 (Home) X-Comment: Ignore error messages for "ole@radiomail.net" Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report Interop Company, 480 San Antonio Road, Suite 100 Mountain View, CA 94040, Phone: (415) 962-2515 FAX: (415) 949-1779 Email: ole@csli.stanford.edu When encoded as a PCI header, this becomes: Ole J Jacobsen: name: Ole J. Jacobsen email: ole@csli.stanford.edu; work <title: Editor & Publisher; org: Interop Company; dept: Connexions -- The Interoperability Report; street: 480 San Antonio Rd., Suite 100; geo: Mountain View / CA / US; code: 94040; phone: +1 415 962 2515; fax: +1 415 949 1779> home <phone: +1 415 550 9427; fax: +1 415 826 2008> mobile <phone: +1 415 990 9427; pager <phone: +1 415 998 4427> > note: Ignore error messages for "ole@radiomail.net" Note that the entire entry is tagged with a canonical form of the person's name. This tag is different from the formal presentation string for that person's name. That is, name is different from the header-name for the header containing the name field. Leading and trailing information, such as "Dr." or "Ph.D." and "Jr." should be removed from the header-name, to faciliate use of this string as a database storage and search key.